Skip to content

Conversation

@itsmeichigo
Copy link
Contributor

@itsmeichigo itsmeichigo commented Sep 11, 2025

Part of WOOMOB-1125

Description

This PR tracks new events for the network switching:

  • jetpack_site_eligible_for_app_password_support: tracked when a Jetpack site is detected as eligible to switch to application password authentication for network requests.
  • jetpack_site_flagged_unsupported_for_app_passwords tracked when a site is flagged as not supported for app passwords. This comes with properties:
    • flow: app_password_generation or api_request
    • cause: major_error or general_failures_threshold_reached.
    • api_error_code
    • http_status_code

To add these events, the error handling needs to be updated to pass the errors for tracking:

  • RequestProcessor:
    • Sends the failure when app password generation fails with expected errors to the delegate.
    • Sends the failure when the generation fails with general errors.
  • AlamofireNetworkErrorHandler:
    • Sends notification for tracking when network switching starts
    • Determines the flow, cause, error codes to send notification for tracking failures.
    • Adds logs for when network switched requests fail. This would be helpful during support when users disable tracking on the app.
  • DefaultStoresManager: clear app password locally to avoid the app picking up the password from a previous site upon switching sites, causing requests to fail with HTTP code 401 and error incorrect_username.

Testing steps

Use the test plan in pe5sF9-4Am-p2:

  1. With TC1, confirm that jetpack_site_eligible_for_app_password_support is tracked after login (with an acceptable delay)
  2. With TC3 to TC6 confirm that at the end, jetpack_site_flagged_unsupported_for_app_passwords is tracked with the following properties:
\ flow cause api_error_code http_status_code
TC3 app_password_generation major_error application_passwords_disabled 501
TC4 (snippet 1) api_request major_error incorrect_password 501
TC5 api_request general_failures_threshold_reached error 500
TC6 app_password_generation general_failures_threshold_reached general_error 500

Testing information

Tested and confirm the above cases with simulator iPhone 16 iOS 18.2.

Screenshots

N/A


  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@itsmeichigo itsmeichigo added this to the 23.3 milestone Sep 11, 2025
@itsmeichigo itsmeichigo added type: task An internally driven task. category: tracks Related to analytics, including Tracks Events. labels Sep 11, 2025
@dangermattic
Copy link
Collaborator

dangermattic commented Sep 11, 2025

1 Message
📖

This PR contains changes to Tracks-related logic. Please ensure (author and reviewer) the following are completed:

  • The tracks events must be validated in the Tracks system.
  • Verify the internal Tracks spreadsheet has also been updated.
  • Please consider registering any new events.
  • The PR must be assigned the category: tracks label.

Generated by 🚫 Danger

@wpmobilebot
Copy link
Collaborator

wpmobilebot commented Sep 11, 2025

App Icon📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

App NameWooCommerce iOS Prototype
Build Numberpr16118-0010d8a
Version23.2
Bundle IDcom.automattic.alpha.woocommerce
Commit0010d8a
Installation URL3bo64gd4garn8
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

@itsmeichigo itsmeichigo marked this pull request as ready for review September 11, 2025 11:04
Copy link
Contributor

@RafaelKayumov RafaelKayumov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM. Scenarios work as described. Found just one issue. Pre-approving.

  • ⚠️ TC1. I repeated the flow by logging out and logging in for several times without restarting the app. I can see numerous repetitive "Tracked" logs for the same event. I guess the observer/subscription was created but never cleared after a login or smth. Probably not related to the flow itself but to notification observer stacking.
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: []
🔵 Tracked jetpack_site_eligible_for_app_password_support, properties: [blog_id: <blogid> site_url: <siteurl>, plan: ecommerce-bundle, is_wpcom_store: true, was_ecommerce_trial: true]
  • ✅ TC3
🔵 Tracked jetpack_site_flagged_unsupported_for_app_passwords, properties: [plan: jetpack_free, is_wpcom_store: false, store_id: <store id>, cause: major_error, api_error_code: application_passwords_disabled, flow: app_password_generation, http_status_code: 501, site_url: <site url>, blog_id: <blog id>, was_ecommerce_trial: false]
  • ✅ TC4
🔵 Tracked jetpack_site_flagged_unsupported_for_app_passwords, properties: [http_status_code: 501, cause: major_error, flow: api_request, blog_id: <blog id>, api_error_code: incorrect_password, was_ecommerce_trial: false, store_id: <store id>, is_wpcom_store: false, site_url: <site url>, plan: jetpack_free]
  • ✅ TC5
🔵 Tracked jetpack_site_flagged_unsupported_for_app_passwords, properties: [http_status_code: 500, store_id: <store id>, cause: general_failures_threshold_reached, is_wpcom_store: false, blog_id: <blog id>, site_url: <site url>, plan: jetpack_free, api_error_code: error, flow: api_request, was_ecommerce_trial: false]
  • ✅ TC6
🔵 Tracked jetpack_site_flagged_unsupported_for_app_passwords, properties: [api_error_code: general_error, site_url: <site url>, is_wpcom_store: false, cause: general_failures_threshold_reached, was_ecommerce_trial: false, plan: jetpack_free, flow: app_password_generation, blog_id: <blog id>, store_id: <store id>, http_status_code: 500]

@itsmeichigo
Copy link
Contributor Author

I repeated the flow by logging out and logging in for several times without restarting the app. I can see numerous repetitive "Tracked" logs for the same event.

Good catch @RafaelKayumov! The issue was from the login flow where we authenticate a few times, causing the AuthenticatedState to be created multiple times, hence the number of events.

I moved the observers of notifications to DefaultStoresManager to keep track of tracked sites since this class is a singleton. Please take another look and let me know if this works.

Copy link
Contributor

@RafaelKayumov RafaelKayumov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx! LGTM

@itsmeichigo itsmeichigo merged commit 13a4bc6 into trunk Sep 12, 2025
14 checks passed
@itsmeichigo itsmeichigo deleted the woomob-1125-failures-tracking branch September 12, 2025 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category: tracks Related to analytics, including Tracks Events. type: task An internally driven task.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants